\section{Pruebas unitarias}
	Según Wikipedia\cite{unittest}, una prueba unitaria es una forma de probar el correcto funcionamiento de un módulo de código. Esto sirve 
	para asegurar que cada uno de los módulos funcione correctamente por separado. Luego, con las pruebas de integración, se podrá asegurar 
	el correcto funcionamiento del sistema o subsistema en cuestión. La idea es escribir casos de prueba para cada función no trivial o método en 
	el módulo de forma que cada caso sea independiente del resto.

	\subsection*{Características}
		Según Wikipedia\cite{unittest}, para que unas pruebas unitarias sean buenas deben ser de la siguiente manera:
		
		\begin{itemize}
			\item \textbf{Automáticas}: No debe requerirse una intervención manual. Esto es especialmente útil para la integración 
			continua\cite{continuous-integration}.
			\item \textbf{Completas}: Deben cubrir la mayor cantidad de código.
			\item \textbf{Repetibles o reutilizables}: No deben crearse pruebas que sólo puedan ser ejecutadas una sola vez. 
			También es útil para integración continua.
			\item \textbf{Independientes}: La ejecución de una prueba no debe afectar a la ejecución de otra.
			\item \textbf{Profesionales}: Las pruebas deben ser consideradas igual que el código, con la misma profesionalidad, documentación, etc.
		\end{itemize}
			
	\subsection*{Ventajas}
		Según Wikipedia\cite{unittest}, el objetivo de las pruebas unitarias es aislar cada parte del programa y mostrar que las partes individuales 
		son correctas. Proporcionan un contrato escrito que el trozo de código debe satisfacer. Estas pruebas aisladas proporcionan cinco ventajas básicas:
			
		\begin{itemize}
			\item \textbf{Fomento del cambio}: Las pruebas unitarias facilitan que el programador cambie el código para mejorar su estructura 
			(lo que se ha dado en llamar refactorización\cite{refactoring}), puesto que permiten hacer pruebas sobre los cambios y así asegurarse 
			de que los nuevos cambios no han introducido errores.
			\item \textbf{Simplificación de la integración}: Puesto que permiten llegar a la fase de integración con un grado alto de seguridad de que 
			el código está funcionando correctamente. De esta manera se facilitan las pruebas de integración\cite{integration-tests}.
			\item \textbf{Documentación del código}: Las propias pruebas son documentación del código puesto que ahí se puede ver cómo utilizarlo.
			\item \textbf{Separación de la interfaz y la implementación}: Dado que la única interacción entre los casos de prueba y las unidades bajo prueba 
			son las interfaces de estas últimas, se puede cambiar cualquiera de los dos sin afectar al otro, a veces usando objetos \textit{mock}
			\cite{mock-objects} para simular el comportamiento de objetos complejos.
			\item \textbf{Mayor acotación y mayor facilidad de localizar de los errores}: Dado que tenemos pruebas unitarias que pueden desenmascararlos.
		\end{itemize}
			
	\subsection*{Limitaciones}
		Según Wikipedia\cite{unittest}, es importante darse cuenta de que las pruebas unitarias no descubrirán todos los errores del código. 
		Por definición, sólo prueban las unidades por sí solas. Por lo tanto, no descubrirán errores de integración, problemas de rendimiento y otros 
		problemas que afectan a todo el sistema en su conjunto. Además, puede no ser trivial anticipar todos los casos especiales de entradas que puede 
		recibir en realidad la unidad de programa bajo estudio. Las pruebas unitarias sólo son efectivas si se usan en conjunto con otras pruebas de software
		\cite{software-testing}.
